home *** CD-ROM | disk | FTP | other *** search
Text File | 1998-10-30 | 60.1 KB | 1,255 lines
LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) NNNNAAAAMMMMEEEE ld - link editor SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS lllldddd [ _o_p_t_i_o_n ] ... _f_i_l_e ... DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _L_d, the link editor, links _E_l_f _o_b_j_e_c_t _f_i_l_e_s. The archive format lllldddd uses is the one created by the archiver _a_r(1). _l_d is normally invoked by _c_c(1), although it can be run separately. When _l_d is used as part of a _c_c compilation, the _l_d _o_p_t_i_o_ns must be passed via the ----WWWWllll mechanism. See _c_c(1) for details of ----WWWWllll. The lllldddd command combines several object files into one, performs relocation, resolves external symbols, builds tables and relocation information for run-time linkage in case of shared linking, and supports symbol table information for symbolic debugging. In the simplest case, the names of several object _f_i_l_e_s are given. lllldddd combines them, producing an object module that can be executed or used as input for a subsequent lllldddd run. (In the latter case, the ----rrrr option must be given to preserve the relocation entries.) The output of lllldddd is left in _a._o_u_t. By default, this file is a dynamic executable if no errors occurred during the link. Usually, lllldddd is invoked by the compiler driver as the final step in compilation. Only under special circumstances is it necessary to run it separately. The sections within the argument object files are combined, some by merging and others by concatenation. The order in which this is done may be specified. The entry point of the output is the first instruction in the text segment (unless the ----eeee option is specified). If any argument is a library, it is searched exactly once at the point it is encountered in the argument list. There are two kinds of libraries, archives and dynamic shared objects. When linking with archives, only those routines defining an unresolved external reference are loaded. Shared objects are used only if the output is to be dynamic. In that case, only the name is used for external resolution, no object is included as part of the output object file. Note, unresolved symbols are not considered an error when linking ----sssshhhhaaaarrrreeeedddd. The library (archive) symbol table (see _a_r(1)) is a hash table and is searched to resolved external references that can be satisfied by library members. The ordering of library members is NNNNOOOOTTTT important. Linking against a dynamic shared object will normally cause that object to be loaded at runtime (see _r_l_d(1) and _d_s_o(5)) whenever the object being created is loaded, thus resolving the symbols supplied by that object. The loading of a dynamic shared object can be delayed using the ----ddddeeeellllaaaayyyy____llllooooaaaadddd option. In this case the object is not loaded until a symbol supplied by the object is actually referenced. Symbols from a delay loaded object do not preempt symbols from other libraries; they are PPPPaaaaggggeeee 1111 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) resolved as if the object was last on the link line. When searching for ucode libraries the default directories searched are /_u_s_r/_l_i_b/, /_l_i_b/ and /_u_s_r/_l_o_c_a_l/_l_i_b/. Note that, although archives will be found in /_u_s_r/_l_o_c_a_l/_l_i_b/, shared objects should not be installed there, as they will not be found by _r_l_d(1). When searching for 64bit libraries the default directories searched are /_u_s_r/_l_i_b_6_4/, /_l_i_b_6_4/ and /_u_s_r/_l_o_c_a_l/_l_i_b_6_4/. When searching for n32 libraries the default directories searched are /_u_s_r/_l_i_b_3_2/, /_l_i_b_3_2/ and /_u_s_r/_l_o_c_a_l/_l_i_b_3_2/. RRRReeeesssseeeerrrrvvvveeeedddd SSSSyyyymmmmbbbboooollllssss The symbols `.bss', `.comment', `.data', `.fini', `.init', `.lit4', `.lit8', `.rdata', `.sbss', `.sdata', `.text', `_BASE_ADDRESS', `_DYNAMIC', `_DYNAMIC_LINK', `_DYNAMIC_LINKING', `_GOT_OFFSET', `__dso_displacement', `__elf_header', `__fstart', `__istart', `__lcldta_address', `__lcldta_size', `__program_header_table', `__rld_obj_head', `__start', `__unwind', `_data_init_table', `_edata', `_end', `_etext', `_fbss', `_fdata', `_ftext', `_gp', `_gp_disp', `_lib_version', `_procedure_string_table', `_procedure_table', `_procedure_table_size', `_rld_new_interface', `_rt_symbol_string_table', `_rt_symbol_table', `_rt_symbol_table_size', and all symbols beginning with the prefixes `__elf_vaddr' and `__elf_size' are reserved. It is erroneous to define these symbols. In ANSI C the symbols `end', `edata', and `etext' may be user defined. (see the description of ----ssssttttdddd below.) If they are not defined (but only referenced) they are assigned the same values as `_end', `_edata', and `_etext' respectively. More information on these symbols is available in _e_n_d(3C). SSSSyyyymmmmbbbboooollll RRRReeeessssoooolllluuuuttttiiiioooonnnn //// IIIInnnnppppuuuutttt SSSSeeeeaaaarrrrcccchhhhppppaaaatttthhhh OOOOppppttttiiiioooonnnnssss ----llll_x Search a library lllliiiibbbb_x....{{{{ssssoooo,,,,_a}, where _x is a string. A shared object or an archive is searched when its name is encountered, so the placement of a ----llll is significant. ----LLLL _d_i_r Change the algorithm of searching for lllliiiibbbb_x....{{{{ssssoooo,,,,_a} or lllliiiibbbb_x....bbbb to look in _d_i_r before looking in the default directories. This option is effective only if it precedes the ----llll options on the command line. Repeating for emphasis: _d_i_r must be a directory. ----LLLL_d_i_r The same as ----LLLL _d_i_r.... ----LLLL Change the algorithm of searching for lllliiiibbbb_x....{{{{ssssoooo,,,,_a} or lllliiiibbbb_x....bbbb to nnnneeeevvvveeeerrrr look in the default directories. This is useful when the default directories for libraries should not be searched and only the directories specified by ----LLLL_d_i_r are to be searched. This option may be dropped from some future release in favor of the ----nnnnoooossssttttddddlllliiiibbbb option. PPPPaaaaggggeeee 2222 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----nnnnoooossssttttddddlllliiiibbbb Change the algorithm of searching for lllliiiibbbb_x....aaaa or lllliiiibbbb_x....bbbb to nnnneeeevvvveeeerrrr look in the default directories. This is useful when the default directories for libraries should not be searched and only the directories specified by ----LLLL ddddiiiirrrr are to be searched. ----BBBB [_s_t_a_t_i_c|_d_y_n_a_m_i_c|_s_y_m_b_o_l_i_c] In dynamic mode (the default), ld searches each directory specified in the library search path for a file libx.so, and if not available then libx.a. When -B _s_t_a_t_i_c is specified, ld selects only the files ending in .a (except for libc). If it is desired to link with static libraries, but not all of the needed .a files are available: cc prog.o -o prog -B static -lXm -lXt -B dynamic -lX11 -lgen When -B _s_y_m_b_o_l_i_c is specified, ld inserts the element DT_SYMBOLIC into the .dynamic section of a shared object library and this alters the dynamic linker's symbol resolution algorithm for references within the library. Instead of starting a symbol search with the executable file, the dynamic linker starts from the shared object itself. If the shared object fails to supply the referenced symbol, the dynamic linker then searches the executable file and other shared objects as usual. ----uuuu symname Enter _s_y_m_n_a_m_e as an undefined in the symbol table. This is useful for loading entirely from a library, since initially the symbol table is empty and an unresolved reference is needed to force the loading of the first routine. ----ssssttttdddd Specifies that the linker should not define certain symbol names, e.g. `_e_n_d`, `_e_d_a_t_a`, _a_n_d `_e_t_e_x_t`. ----cccccccckkkkrrrr Specifies that the linker should set the value of the variable `__l_i_b__v_e_r_s_i_o_n` _t_o _s_p_e_c_i_f_y _n_o_n-_a_n_s_i _s_e_m_a_n_t_i_c_s _t_o see eeeennnndddd((((3333)))).... ----ccccxxxxxxxx Specifies special handling of certain symbols needed for proper linkage and execution of C++ programs. IIIInnnnppppuuuutttt SSSSppppeeeecccciiiiffffiiiiccccaaaattttiiiioooonnnn OOOOppppttttiiiioooonnnnssss ----ffffrrrroooommmm _o_p_t_i_o_n_l_i_s_t_f_i_l_e This allows one to specify arguments to lllldddd in a file. Read the file _o_p_t_i_o_n_l_i_s_t_f_i_l_e as if it appeared on the command line in the same PPPPaaaaggggeeee 3333 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) position as the ----ffffrrrroooommmm option. Newlines in _o_p_t_i_o_n_l_i_s_t_f_i_l_e are treated as if they were ordinary spaces. ----oooobbbbjjjjeeeeccccttttlllliiiisssstttt _o_b_j_e_c_t_l_i_s_t_f_i_l_e Read the file _o_b_j_e_c_t_l_i_s_t_f_i_l_e to obtain a list of files. By putting the list of files in _o_b_j_e_c_t_l_i_s_t_f_i_l_e instead of on the command line one avoids exceeding the limit on the length of a command line. This is primarily useful when linking very large programs with many objects and long filenames. The _o_b_j_e_c_t_l_i_s_t_f_i_l_e is a list of file or archive names, one file per line. Blank lines are silently ignored. Leading white space is ignored. A filename is considered ended by the next whitespace character. Characters after the filename are ignored. Any leading ``-'' in an _o_b_j_e_c_t_l_i_s_t_f_i_l_e line is considered part of a filename: nothing in the file is taken as an option. Lines are in the file are limited to BUFSIZ*2 characters (16K bytes) each. ----aaaallllllll Link in all of the objects from all archives following this flag. This option is commonly used in conjunction with ----sssshhhhaaaarrrreeeedddd option to create a shared object out of an existing archive. ----nnnnoooottttaaaallllllll Turns off ----aaaallllllll.... This still allows objects to be pulled out of the archive into a DSO if these objects resolve unresolved symbols in the already included object, but these objects are included without exporting their symbols by default. ----eeeexxxxcccclllluuuuddddeeee _o_b_j_e_c_t Used in conjunction with ----aaaallllllll and ----sssshhhhaaaarrrreeeedddd.... The object specified will be excluded in making the shared object. ----nnnnoooo____aaaarrrrcccchhhhiiiivvvveeee Requires that ----llll references must resolve to shared objects. Normally, if the shared object as specified by the ----llll is not found, the linker attempts to find the corresponding archive to resolve undefines. This option disallow using those archives. This is a synonym of ----BBBBddddyyyynnnnaaaammmmiiiicccc.... DDDDeeeebbbbuuuuggggggggiiiinnnngggg OOOOppppttttiiiioooonnnnssss ----aaaaoooouuuuttttkkkkeeeeeeeepppp By default, ld removes the output file if there are link errors. But when this flag is set, the output file will be rename to aaaa....oooouuuutttt .... PPPPaaaaggggeeee 4444 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----mmmm Produce a map or listing of the input/output sections on the standard output (UNIX system V-like map). ----MMMM Produce a primitive load map, listing the names of the files that will be loaded (UNIX 4.3bsd-like map). ----ggggppppiiiinnnnffffoooo Produce a listing of short data section components (page pointers, GOT pointers, small data, and small literals). This may be useful in identifying modules with large gp relative sections. In cases where ----mmmmuuuullllttttiiiiggggooootttt won't work, recompiling these modules with -G0 may allow a successful link. ----vvvv Set verbose mode. Print the name of each file as it is processed. ----qqqquuuuiiiicccckkkkssssttttaaaarrrrtttt____iiiinnnnffffoooo Prints extra information regarding the quickstart status of the executable file created, including a full list of conflict symbols and their objects of origin. ----yyyy_s_y_m Indicate each file in which _s_y_m appears, _s_y_m's type and whether the file defines or references _s_y_m. Many such options may be given to trace many symbols. Each ----yyyy_s_y_m applies to those files listed after this option on the command line. ----VVVV Print a message giving information about the version of lllldddd being used. ----ffff _f_i_l_l Set the fill pattern for ``holes'' within an output section. The argument _f_i_l_l is a four-byte hexadecimal constant. ----sssshhhhoooowwww____uuuunnnnrrrreeeeffff Defined but unreferenced symbols will be listed. This flag is useful for finding out "dead code" in a program. Note that it is normal behavior for many library routines to define symbols that might not be referenced by all programs. Also, in the case of weak and strong symbol pair where two different symbols point to the same virtual address, if only one of them is referenced, the other symbol is still listed. This does not necessarily mean the specified function is never used. PPPPaaaaggggeeee 5555 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) MMMMeeeessssssssaaaaggggeeee OOOOppppttttiiiioooonnnnssss ----LLLLDDDD____MMMMSSSSGGGG::::[[[[mmmmssssggggttttyyyyppppeeee====nnnnuuuummmmlllliiiisssstttt]]]][[[[::::mmmmssssggggttttyyyyppppeeee====nnnnuuuummmmlllliiiisssstttt]]]]........ General message handling interface for ld that allows the user to select the message type of the specified message numbers. The _n_u_m_l_i_s_t is a comma (',') or dash ('-') separated list of message numbers. eeeerrrrrrrroooorrrr====_n_u_m_l_i_s_t Treat each message on the _n_u_m_l_i_s_t as an error. wwwwaaaarrrrnnnniiiinnnngggg====_n_u_m_l_i_s_t Treat each message on the _n_u_m_l_i_s_t as a warning. iiiinnnnffffoooo====_n_u_m_l_i_s_t Treat each message on the _n_u_m_l_i_s_t as an info message. vvvveeeerrrrbbbboooosssseeee====_n_u_m_l_i_s_t Treat each message on the _n_u_m_l_i_s_t as a verbose message. ooooffffffff====_n_u_m_l_i_s_t Ignore each message on the _n_u_m_l_i_s_t. For example, ----LLLLDDDD____MMMMSSSSGGGG::::wwwwaaaarrrrnnnniiiinnnngggg====33333333 tells the linker to treat message 33, which by default is an error, as a warning. Similarly, ----LLLLDDDD____MMMMSSSSGGGG::::wwwwaaaarrrrnnnniiiinnnngggg====33333333::::ooooffffffff====44447777----66668888 tells the linker to treat message 33 as a warning and to ignore all messages from 47 to 68 inclusive. Fatal errors can not be modified by ----LLLLDDDD____MMMMSSSSGGGG:::: ----UUUU Undefined symbols are not considered an error when this is supplied. As a result, one can create an executable with undefined symbols. Referencing an undefined symbol during execution may cause a segmentation fault and a core dump. ----wwwwooooffffffff _n_u_m_l_i_s_t This allows a user to specify a comma-separated list of numbers of warnings which the linker is to suppress. For example, ----wwwwooooffffffff 5555,,,,11117777,,,,22223333 turns off warnings numbered 5, 17 and 23. If you are linking using the cccccccc(_1) command, this flag should be passed to the linker with, ----WWWWllll,,,,----wwwwooooffffffff,,,,5555 ----WWWWllll,,,,----wwwwooooffffffff,,,,11117777 ----WWWWllll,,,,----wwwwooooffffffff,,,,22223333.... ----wwww This flag specifies that all warnings are to be suppressed. ----iiiinnnnffffoooo Enable the linker to print out messages of an informational nature which might highlight unusual, but not illegal situations. This is on by default. PPPPaaaaggggeeee 6666 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----nnnnooooiiiinnnnffffoooo Disable the -info level of error messages as described above. ----ddddeeeemmmmaaaannnngggglllleeee Specifies that demangling of C++ names should take place when printing other messages. ----iiiiggggnnnnoooorrrreeee____uuuunnnnrrrreeeessssoooollllvvvveeeedddd This option causes an executable or DSO to be produced and ld to exit with zero status even if there are unresolved symbols; resolution of these symbols will be completed by rrrrlllldddd .... If linking -call_shared, a list of the unresolved symbols will be output (as it always is for -call_shared). If linking -shared, no such list will be output. If linking -non_shared, this option is ignored (and -no_unresolved is used, as it always is for -non_shared). This option is the default for -shared linking, but not for -call_shared or -non_shared. ----nnnnoooo____uuuunnnnrrrreeeessssoooollllvvvveeeedddd Unresolved symbols will be listed. If linking -shared, a DSO will still be produced (as it always is for -shared) and ld will exit with zero status. If linking -call_shared or -non_shared, ld will exit with nonzero status and no executable will be produced. This option is the default for -call_shared and -non_shared link, but not for -shared. ----wwwwaaaarrrrnnnn____uuuunnnnuuuusssseeeedddd This flag specifies that the linker should issue a warning if it finds that some object has not been used in a link. The semantics of dynamic linking dictate that this cannot be determined absolutely at static link time, but it is usually quite reliable. This is the default. ----ddddoooonnnntttt____wwwwaaaarrrrnnnn____uuuunnnnuuuusssseeeedddd Turns off the warning specified by ----wwwwaaaarrrrnnnn____uuuunnnnuuuusssseeeedddd.... ----aaaalllllllloooowwww____mmmmiiiissssssssiiiinnnngggg When using an ELF layout specification file with the SSSSttttrrrriiiippppppppiiiinnnngggg OOOOppppttttiiiioooonnnnssss ----ssss Strip the symbolic information from the output object file. PPPPaaaaggggeeee 7777 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----xxxx Do not preserve local (non-global) symbols in the output symbol table; enter external and static symbols only. This option saves some space in the output file. OOOOuuuuttttppppuuuutttt OOOObbbbjjjjeeeecccctttt FFFFoooorrrrmmmmaaaatttt OOOOppppttttiiiioooonnnnssss ----rrrr Retain relocation entries in the output file. Relocation entries must be saved if the output file is to become an input file in a subsequent lllldddd run. This option also prevents final definitions from being given to common symbols, and suppresses the `undefined symbol' diagnostics. ----eeeellllffff Produce ELF output object file. This is the default and currently the only file format supported. ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd Produce a static executable. The output object created will not use any shared objects during execution. This declares that you are doing non-PIC loading. ----sssshhhhaaaarrrreeeedddd Produce a dynamic shared object. This includes creating all of the tables for run-time linking and resolving references to other specified shared objects. The object created may be used by the linker to make dynamic executables. ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd Produce a dynamic executable. The object created may use shared objects at run-time. This is the default. ----oooo33332222 oooorrrr ----33332222 Specifies that the object to be linked (and the input objects) are to be 32-bit ucode objects. ----nnnn33332222 Specifies that the object to be linked (and the input objects) are to be 32-bit n32 objects. ----66664444 Specifies that the object to be linked (and the input objects) are to be 64-bit objects. ----mmmmiiiippppssss1111 Specifies that the linker should try to produce a binary that conforms to the MIPS 1 ISA. If _l_d finds object files that are MIPS PPPPaaaaggggeeee 8888 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) 2, the resulting binary will silently be marked as being a ----mmmmiiiippppssss2222 binary. ( NNNNOOOOTTTTEEEE:::: Because all ----oooo33332222 format object files shipped by SGI are built ----mmmmiiiippppssss2222 , it may not be possible to produce a ----mmmmiiiippppssss1111 executable.) ----mmmmiiiippppssss2222 Specifies that the linker should try to produce a binary that conforms to the MIPS 2 ISA. ----mmmmiiiippppssss3333 Specifies that the linker should try to produce a binary that conforms to the MIPS 3 ISA. If _l_d finds object files that are MIPS 4, the resulting binary will silently be marked as being a ----mmmmiiiippppssss4444 binary. ----mmmmiiiippppssss4444 Specifies that the linker should try to produce a binary that conforms to the MIPS 4 ISA. LLLLaaaayyyyoooouuuutttt OOOOppppttttiiiioooonnnnssss ----LLLLDDDD____LLLLAAAAYYYYOOOOUUUUTTTT::::[[[[ttttyyyyppppeeee====aaaarrrrgggg]]]][[[[::::ttttyyyyppppeeee====aaaarrrrgggg]]]]........ Commands that affect object layout. sssseeeegggglllliiiiggggnnnn====_a_l_i_g_n_v_a_l Defines the minimum segment alignment to be _a_l_i_g_n_v_a_l. This value needs to be both 0x1000 or greater and a power of 2. ----dddd Force definition of common storage and define loader defined symbols even if ----rrrr is present. ----zzzz Arrange that the process pages are loaded on demand from the resulting executable file rather than preloaded, and that the text pages are shared among all users. This is the default. ----mmmmuuuullllttttiiiiggggooootttt Create multiple Global Offset Tables. All entries in the GOT need to be accessible from a 16 bit offset from a common GP (Global Pointer). If the GOT grows too big you may get a "gp out of range" error at link time. This option will allow the linker to create multiple GOTs and GPs thus avoiding the error. This is position dependent and should appear before any objects on the command line. Having multiple GOTs will neither increase code size nor affect performance. This option is only usable with PIC code: it is not appropriate or useful with code compiled or linked -non_shared. PPPPaaaaggggeeee 9999 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----nnnn Arrange that when the output file is executed, the entire text and data portions of the executables are preloaded. This involves moving the data areas up to the first possible _p_a_g_e_s_i_z_e byte boundary following the end of the text. User must specify -non_shared when -n is used. ----NNNN Place the data segment immediately after the text and do not make the text portion read only or sharable. Only objects compiled ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd can be linked with ----NNNN.... ----TTTT _n_u_m Set the text segment origin. The argument _n_u_m is a hexadecimal number. ----DDDD _n_u_m Set the data segment origin. The argument _n_u_m is a hexadecimal number. Please note that this switch is non-standard, and may not be supported across product lines. ----BBBB _n_u_m Set the bss segment origin. The argument _n_u_m is a hexadecimal number. Please note that this switch is non-standard, and may not be supported across product lines. ----GGGG _n_u_m If the flag -_SYSTYPE_SVR4 has been specified, this flag is a synonym for -shared, and takes no numerical argument. Otherwise, The argument _n_u_m is taken to be a decimal number that is the largest size in bytes of a ._c_o_m_m item that is to be allocated in the small bss section for reference off the global pointer. The default is 8 bytes. Please note that this switch is non-standard, and may not be supported across product lines. ----rrrrddddaaaattttaaaa____wwwwrrrriiiittttaaaabbbblllleeee Puts .rodata into the "data" segment, which has the "WRITE" permission. This is the default. ----rrrrddddaaaattttaaaa____sssshhhhaaaarrrreeeedddd Puts .rodata into the "text" segment, where it will be shared across processes, and will be read-only. ----iiiivvvvppppaaaadddd Improves cache behavior by causing the linker to perform intervariable padding of some large variables. ----nnnnooooiiiivvvvppppaaaadddd Turns off ----iiiivvvvppppaaaadddd.... PPPPaaaaggggeeee 11110000 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----XXXXllllooooccccaaaallll _n_a_m_e,... Assigns the named global bss (uninitialized data) symbols to a special llllooooccccaaaallll ddddaaaattttaaaa section in the a.out. This is useful for hand-parallelized FFFFoooorrrrttttrrrraaaannnn programs that require this symbol to be private for each thread. A symbol assigned to the _s_m_a_l_l _b_s_s or _s_m_a_l_l _d_a_t_a section of an object file cannot be moved to the special section. If the symbol gets assigned to one of small bss/data section, then either recompile with a smaller ----GGGG number or use the following pragma in your source code: #pragma section_non_gp(_n_a_m_e) in C or c*$*section_non_gp(_n_a_m_e) in FFFFoooorrrrttttrrrraaaannnn. ----eeeellllssssppppeeeecccc eeeellllssssffffiiiilllleeee This flag specifies a file to serve as an ELF layout specification file. This file and its syntax are described in eeeellllssssppppeeeecccc((((5555)))).... ----eeeellllssssmmmmaaaapppp This flag specifies that the linker should emit a layout map in the form of an ELF layout specification. The output from this specification can be used with the ----eeeellllssssppppeeeecccc flag without modification. ----cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy _l_o_c_a_t_i_o_n__f_i_l_e Check the location of this shared object's segments and make sure they stay out of the way of others in the location_file. A single registry file, either with ----cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy or ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy is allowed. This option is used with ----sssshhhhaaaarrrreeeedddd.... ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy _l_o_c_a_t_i_o_n__f_i_l_e Register the location of this shared object's segments and make sure they stay out of the way of others in the location_file. Location_file is updated if it is writable. A single registry file, either with ----cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy or ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy is allowed. This option is used with ----sssshhhhaaaarrrreeeedddd.... The default registry file is /usr/lib{,32,64}/so_locations. See the ddddssssoooo((((5555)))) manpage for details on so_locations. DDDDyyyynnnnaaaammmmiiiicccc OOOOppppttttiiiioooonnnnssss ----eeee _e_p_s_y_m Set the default entry point address for the output file to be that of the symbol _e_p_s_y_m. PPPPaaaaggggeeee 11111111 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----IIII ppppaaaatttthhhh____nnnnaaaammmmeeee The path_name is a path name for the system to invoke as a program interpreter. This option writes the path name into the .interp section. ----ddddeeeeffffaaaauuuulllltttt____ddddeeeellllaaaayyyy____llllooooaaaadddd When creating a dynamic shared object using ----sssshhhhaaaarrrreeeedddd,,,, it marks that shared object as default delay load. ----ddddeeeellllaaaayyyy____llllooooaaaadddd Indicates that the next specified object, if it is a dynamic shared object, should be delay loaded. ----ffffoooorrrrcccceeee____llllooooaaaadddd Forces the normal loading of the next specified object, overriding any default delay load attribute associated with that object. This flag is used when creating a dynamic object ( ----sssshhhhaaaarrrreeeedddd or ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd)))).... It indicates that symbols from the next object, archive, or dynamic shared object will be exported by the object being created. This is the default behavior for linking in an object but not for archives or dynamic shared objects. ----hhhhiiiiddddeeeessss This flag is used when creating a dynamic object ( ----sssshhhhaaaarrrreeeedddd or ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd)))).... It indicates that symbols from the next object, archive, or dynamic shared object will be hidden by the object being created. This is the default behavior for linking in archives or dynamic shared objects, but not for objects. ----eeeexxxxppppoooorrrrtttteeeedddd____ssssyyyymmmmbbbboooollll _n_a_m_e,... Used in conjunction with ----sssshhhhaaaarrrreeeedddd or ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd.... This marks the symbol given by the list of names as exported. If you specify any exported symbols, then all unspecified symbols are automatically hidden. ----eeeexxxxppppoooorrrrttttssss____ffffiiiilllleeee _f_i_l_e_n_a_m_e Used in conjunction with ----sssshhhhaaaarrrreeeedddd or ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd.... The file given by filename contains a list of symbols that should be exported. The list is space separated (including newlines). Any symbols not specifically exported will be automatically hidden. ----hhhhiiiiddddddddeeeennnn____ssssyyyymmmmbbbboooollll_n_a_m_e,... Used in conjunction with ----sssshhhhaaaarrrreeeedddd or ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd.... This marks the symbol given by the list of names as hidden. This is ignored if any PPPPaaaaggggeeee 11112222 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) symbols are specifically marked as exported using the ----eeeexxxxppppoooorrrrtttteeeedddd____ssssyyyymmmmbbbboooollll or ----eeeexxxxppppoooorrrrttttssss____ffffiiiilllleeee options. ----hhhhiiiiddddddddeeeennnnssss____ffffiiiilllleeee _f_i_l_e_n_a_m_e Used in conjunction with ----sssshhhhaaaarrrreeeedddd or ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd.... The file given by filename contains a list of symbols that should be hidden. The list is space separated (including newlines). This list is ignored if any symbols are specifically marked as exported using ----eeeexxxxppppoooorrrrtttteeeedddd____ssssyyyymmmmbbbboooollll or ----eeeexxxxppppoooorrrrttttssss____ffffiiiilllleeee options. ----ttttrrrraaaannnnssssiiiittttiiiivvvveeee____lllliiiinnnnkkkk Normally, every shared object and every executable has a dependency list of shared objects which are needed for correct execution. The runtime linker rrrrlllldddd(_1) will load these objects, when any process is run. If the depended-upon shared objects have more objects which they in turn depend upon, rrrrlllldddd will add them at the end of the list, and so on, performing a transitive closure. By default a similar operation is performed at static ((((lllldddd)))) link time. Any shared object which is listed on the command line is put on a.out's dependency list. Then any new shared objects from the dependency lists of the already-processed shared objects are also processed and checked for conflicting definitions of symbols, but are not added to the list of shared objects needed by the object being built. This is the default behavior. ----nnnnoooo____ttttrrrraaaannnnssssiiiittttiiiivvvveeee____lllliiiinnnnkkkk Some applications may find it desirable to hide some of their dependent libraries. This flag cancels the upward propagation of libraries to facilitate such hiding. Executables and shared objects built in this way may experience slightly slower startup. If you are linking using the cccccccc(_1) command, this flag should be passed both to the driver and the linker, e.g. both ----nnnnoooo____ttttrrrraaaannnnssssiiiittttiiiivvvveeee____lllliiiinnnnkkkk and ----WWWWllll,,,,----nnnnoooo____ttttrrrraaaannnnssssiiiittttiiiivvvveeee____lllliiiinnnnkkkk should be used. ----sssseeeetttt____vvvveeeerrrrssssiiiioooonnnn _v_e_r_s_i_o_n__s_t_r_i_n_g Sets the value of DT_MIPS_IVERSION field in the dynamic section of the shared object to "version_string". The version string is a series of version strings separated by colons(:). ----eeeexxxxaaaacccctttt____vvvveeeerrrrssssiiiioooonnnn Set the LL_EXACT_MATCH flag in .liblist flags field. This indicates to rrrrlllldddd that this shared object must match the timestamp and checksum from the .liblist section in addition to the interface version. This means that all DSOs run against must match, exactly, the version, timestamp, and checksum against which the app was linked (or _r_q_s-d). This means that if the object is copied to another PPPPaaaaggggeeee 11113333 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) machine it will not run unless the object is first _r_q_s-d (because the other machine will surely have a different checksum/timestamp for things on the liblist of this object. Such as libc.so.1). Even more surprising: on a mips4 machine (such as R10000) cc t.c -n32 -mips3 -Wl,-exact_version ; ./a.out will not execute. _r_l_d will report a fatal error because the mips3 libc.so.1 linked against is not the same as the mips4 libc.so.1 against which the executable will run on that machine. ----iiiiggggnnnnoooorrrreeee____vvvveeeerrrrssssiiiioooonnnn Sets the LL_IGNORE_VERSION flag in the liblist flags field. For subsequent shared objects in the liblist. rrrrlllldddd will not try to match the interface version as specified at link time. ----rrrreeeeqqqquuuuiiiirrrreeee____mmmmiiiinnnnoooorrrr Set the LL_REQUIRE_MINOR flag in the .liblist flags field for shared objects listed subsequently on the link line. This indicates to rrrrlllldddd that the shared object used at runtime must have the exact same minor (and major) version number as that at static link time. Otherwise, execution will abort. See the ddddssssoooo((((5555)))) manpage for details on major and minor version numbers. ----iiiiggggnnnnoooorrrreeee____mmmmiiiinnnnoooorrrr Clear the LL_REQUIRE_MINOR flag in the .liblist flags field for shared objects listed subsequently on the link line. This allows rrrrlllldddd to use a shared object at runtime which has a different minor version number. This is the default behavior. See the ddddssssoooo((((5555)))) manpage for details on major and minor version numbers. ----nnnnoooo____lllliiiibbbbrrrraaaarrrryyyy____rrrreeeeppppllllaaaacccceeeemmmmeeeennnntttt Turns on a flag in the dynamic section so that rld does not allow execution time or runtime changing of the path (except for super user) to find the shared objects. Typically, used for security purposes on system utilities. ----rrrrppppaaaatttthhhh lllliiiibbbbrrrraaaarrrryyyy____ppppaaaatttthhhh Sets the rpath (see the generic aaaabbbbiiii ) to the specified string. Meaningful only for shared linkage. ----ssssoooonnnnaaaammmmeeee _s_h_a_r_e_d__o_b_j_e_c_t__n_a_m_e Sets DT_SONAME for a shared object. Use in conjunction with ----sssshhhhaaaarrrreeeedddd option. The name may be a single component name (e.g. libc.a), a full (starting with a slash), or relative pathname (containing a slash). Single component name use rpath, LD_LIBRARY_PATH and the default paths to resolve their locations. PPPPaaaaggggeeee 11114444 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----iiiinnnniiiitttt _i_f_u_n_c_s_y_m_b_o_l Put a call to _i_f_u_n_c_s_y_m_b_o_l in the code rld will exercise before the main program begins. This contains initialization code to be called before control is passed to _m_a_i_n. In the case of a dlopen'd or sgidladd'd DSO, this initialization function is called after the DSO is loaded but before it is referenced. Only a single ----iiiinnnniiiitttt option is effective in a given DSO or executable (if multiple are provided, the last is used). ----iiiinnnniiiitttt is only meaningful when creating a DSO or creating a call-shared executable. ----iiiinnnniiiitttt has no affect on non- shared links. ----ffffiiiinnnniiii _f_f_u_n_c_s_y_m_b_o_l Put a call to _f_f_u_n_c_s_y_m_b_o_l in the code rld will exercise after the main program exits. This contains termination code to be called after the main program exits. In the case of a dlclose'd DSO which is no longer referenced, this function is called before the DSO is unmapped. Only a single ----ffffiiiinnnniiii option is effective in a given DSO or executable (if multiple are provided, the last is used). ----ffffiiiinnnniiii is only meaningful when creating a DSO or creating a call-shared executable. ----ffffiiiinnnniiii has no affect on non-shared links. IIII////OOOO OOOOppppttttiiiioooonnnnssss ----mmmmmmmmaaaapppp This specifies that the linker will use mmmmmmmmaaaapppp((((2222)))) as its preferred mode for reading object files. This usually results in better I/O performances, except when using NFS mounted files with high network latencies. This is the default. ----rrrreeeeaaaadddd This specifies that the linker is to use the _o_p_e_n(_2) , _l_s_e_e_k(_2) , and _r_e_a_d(_2) as its preferred mode for reading object files. Setting this option when many object files are remotely mounted with high network latency often improves performance. HHHHaaaarrrrddddwwwwaaaarrrreeee PPPPaaaattttcccchhhh OOOOppppttttiiiioooonnnnssss ----nnnnoooo____rrrr5555kkkk____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp Works around an R5000 bug present in 1.1 silicon. This option tries to prevent certain classes of branch instructions from being the second to last instruction on an even page of virtual memory. This option is on by default. The hinv(1) command can be used to determine what rev of R5000 is present in the system. PPPPaaaaggggeeee 11115555 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) ----aaaalllllllloooowwww____rrrr5555kkkk____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp Disables the work around for the R5000 bug. When this flag is present, no adjustment is attempted. The work around is enabled by default, the presence of this flag before any object files will turn it off. Turning off this option will result in code that is not compatible across platforms and may also result in a performance penalty some R5000 systems. ----nnnnoooo____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp Works around an R4000 bug present in 2.1 and 2.2 silicon. This option tries to prevent certain classes of branch instructions from being the last instruction on a page of virtual memory. This option is on by default for links of MIPS3 or lower programs. The hinv(1) command can be used to determine what rev of R4000 is present in the system. ----aaaalllllllloooowwww____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp Disables the work around for the R4000 bug. When this flag is present, no adjustment is attempted. The work around is enabled by default, the presence of this flag before any object files will turn it off. Turning off this option will result in code that is not compatible across platforms and may also result in a performance penalty on some R4000 systems. MMMMiiiisssscccceeeellllllllaaaannnneeeeoooouuuussss OOOOppppttttiiiioooonnnnssss ----oooo outfile Produce an output object file by the name _o_u_t_f_i_l_e. The name of the default object file is aaaa....oooouuuutttt. In the event that _o_u_t_f_i_l_e has undefined references at the end of the link editor run, and the ----rrrr option was not used, and the ----aaaaoooouuuuttttkkkkeeeeeeeepppp option was used _o_u_t_f_i_l_e will be renamed aaaa....oooouuuutttt. If there are undefined references and the ----aaaaoooouuuuttttkkkkeeeeeeeepppp option was not used there will be no output from _l_d. ----VVVVSSSS _n_u_m Use _n_u_m as the decimal version stamp to identify the a.out file that is produced. The version stamp is stored in the optional and symbolic headers. ----____SSSSYYYYSSSSTTTTYYYYPPPPEEEE____SSSSVVVVRRRR4444 This flag alters the meaning of the ----GGGG flag to conform to the Unix System V Release 4 usage. See the description below. PPPPaaaaggggeeee 11116666 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) SSSSyyyynnnnoooonnnnyyyymmmm OOOOppppttttiiiioooonnnnssss ----aaaajjjjeeeeoooopppp This is a synonym for ----aaaalllllllloooowwww____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp ----LLLL_d_i_r The same as ----LLLL _d_i_r.... ----LLLL Change the algorithm of searching for lllliiiibbbb_x....{{{{ssssoooo,,,,_a} or lllliiiibbbb_x....bbbb to nnnneeeevvvveeeerrrr look in the default directories. This is useful when the default directories for libraries should not be searched and only the directories specified by ----LLLL_d_i_r are to be searched. This option may be dropped from some future release in favor of the ----nnnnoooossssttttddddlllliiiibbbb option. ----GGGG If the flag -_SYSTYPE_SVR4 has been specified, this flag is a synonym for -shared, and takes no numerical argument. ----WWWWxxxx,,,,----GGGG nnnnuuuummmm This is a synonym for the non-SVR4 meaning of ----GGGG ----hhhh This is a synonym for ----ssssoooonnnnaaaammmmeeee ----ddddyyyy This is a synonym for ----ccccaaaallllllll____sssshhhhaaaarrrreeeedddd ----ddddnnnn This is a synonym for ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd ----aaaa This is a synonym of ----nnnnoooonnnn____sssshhhhaaaarrrreeeedddd.... ----hhhhiiiiddddeeeessss____ffffiiiilllleeee _f_i_l_e_n_a_m_e This is the obsolete version of the ----hhhhiiiiddddddddeeeennnnssss____ffffiiiilllleeee option and will disappear in future releases of the linker. Please change your makefiles to reflect this change. ----nnnnoooonnnneeee Same as ----nnnnoooottttaaaallllllll FFFFIIIILLLLEEEESSSS /lib/lib*.so /lib/lib*.a /usr/lib/lib*.so PPPPaaaaggggeeee 11117777 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) /usr/lib/lib*.a /usr/lib/so_locations /usr/local/lib/lib*.a libraries /lib32/lib*.so /lib32/lib*.a /usr/lib32/lib*.so /usr/lib32/lib*.a /usr/lib32/so_locations /usr/local/lib32/lib*.a libraries /lib64/lib*.so /lib64/lib*.a /usr/lib64/lib*.so /usr/lib64/lib*.a /usr/lib64/so_locations /usr/local/lib64/lib*.a libraries a.out output file SSSSEEEEEEEE AAAALLLLSSSSOOOO cc(1), pc(1), f77(1), as(1), uld(1), ar(1), end(3), collide(1), rqs(1), dso(5) NNNNOOOOTTTTEEEESSSS An object's segments must not overlap and all of the object's addresses must be less than 0x80000000. The stack starts at 0x80000000 and grows down through lower addresses therefore space should be left for it. The default text segment address is 0x10000000 with the data segment immediately following the text segment. The default is that the bss segment follows the data segment. When creating an executable object runnable on Unix, a.out, /_u_s_r/_l_i_b/_c_r_t_1._o Should be the first object loaded and /_u_s_r/_l_i_b/_c_r_t_n._o should be last following any libraries. The compiler drivers (_c_c(1), _f_7_7(1), and _p_c(1)) automatically load these object files in the proper order. Note that if lllldddd is invoked directly, those two objects will not be loaded automatically. It is the user's responsibility to specify them explicitly. A single registry file, either with ----cccchhhheeeecccckkkk____rrrreeeeggggiiiissssttttrrrryyyy or ----uuuuppppddddaaaatttteeee____rrrreeeeggggiiiissssttttrrrryyyy is allowed. If multiple registry files are provided, all except the last one are silently ignored. Be careful when using ----ddddeeeellllaaaayyyy____llllooooaaaadddd or when linking against an object that was built ----ddddeeeeffffaaaauuuulllltttt____ddddeeeellllaaaayyyy____llllooooaaaadddd as the symbol preemption rules are different: symbols are resolved from the delay loaded object as if the object were last on the link line. Archives that are built with ----CCCC produce COFF style archive headers. The linker will no longer recognize such archives. PPPPaaaaggggeeee 11118888 LLLLDDDD((((1111)))) LLLLDDDD((((1111)))) The following group of options have been superseded by the ----eeeellllssssppppeeeecccc functionality: ----XXXXnnnnoooobbbbsssssssscccchhhhaaaannnnggggeeee,,,, ----XXXXnnnnoooossssoooorrrrttttbbbbssssssss,,,, ----XXXXssssoooorrrrttttbbbbssssssss,,,, ----XXXXnnnnddddbbbblllloooocccckkkk,,,, ----XXXXbbbblllloooocccckkkk,,,, ----XXXXbbbblllloooocccckkkkrrrraaaannnnggggeeee,,,, ----XXXXnnnnddddllllooooccccaaaallllddddaaaattttaaaa,,,, ----XXXXaaaalllliiiiggggnnnnbbbbssssssss,,,, ----XXXXnnnnooooaaaalllliiiiggggnnnnbbbbssssssss,,,, ----XXXXccccaaaacccchhhheeeemmmmiiiissssaaaalllliiiiggggnnnn,,,, ----XXXXccccaaaacccchhhheeeessssiiiizzzzeeee,,,, ----XXXXccccaaaacccchhhheeeelllliiiinnnneeeessssiiiizzzzeeee,,,, ----XXXXddddeeeeffffmmmmoooovvvveeeemmmmaaaaxxxx,,,, ----XXXXsssseeeettttaaaalllliiiiggggnnnn,,,, ----XXXXddddeeeebbbbuuuugggg.... The flag ----XXXXllllooooccccaaaallllddddaaaattttaaaa has been replaced by the flag ----XXXXllllooooccccaaaallll.... PPPPaaaaggggeeee 11119999 
